Administrative Advice for UNIX 

R. C. Haight 

AT&T Bell Laboratories 
Murray Hill, New Jersey 07974 

The material presented here is based on the author’s experiences and opinions. Nevertheless, it may prove 
useful. The material on phototypesetting was contributed by D. W. Smith. 

1. ADMINISTRATOR’S ROAD MAP 

Getting started as a UNIXf system administrator is hard work. There are no real shortcuts to a working 
knowledge of the system. You will need time for reading, study and hands-on experimenting. Don’t 
commit yourself to “going live” with your system until you have had two weeks to teach yourself your job, 
and get the initial hardware quirks ironed-out. 

Don’t consign the Setting Up UNIX document to oblivion after your initial system “gen”. In addition to 
needing it again whenever you add/change equipment, you will find that it contains valuable material about 
system tuning (buffers, clists, etc.) that appears nowhere else. 

As an administrator, you should be familiar with a lot of the distributed documentation. The Internals , 
Operations, and Administration papers from Documents for UNIX should all be studied, as well as the 
Introduction , How to Get Started, and most of the entries of the UNIX User’s Manual. In that manual, you 
should pay special attention to: acct*f\M), chmodfl), chown( 1), config(lM), cpio( 1), date( 1), df(\), 
du( 1), ed( 1), env (] ), find{\), fsckfl M), kill{ 1), mail(l), mkdir{\), mkfs{ 1M), ncheckf\M), ps(\), rm(l), 
rmdir( 1), shutdown(lM), stty(l), .sk(I), sync(lM), time(l), volcopyi 1M), wall(\M), who( 1), and write (l) 
in Section 1; all of Section 4; acct(5) in Section 5; and crash{ 8) and vaxops{ 8) in Section 8. 

2. SYSTEM CAPACITY 

The figures below are approximations based on our experience over several years: 


Hardware Configuration 

Number of 
Simultaneous 

Users 

PDP-11/23; 256K-byte memory; 2 RL01 disks* 

4 

PDP-11/34; 256K-byte memory with cache; 

2 RL01 disks* 

8 

PDP-11/45; 248K-byte memory; RP03 disk* 

16 

Above with RP06 (RP04, RP05) disk* 

20 

Above with memory cache 

25 

PDP-11/70; 512K-byte memory; 

RP06 (RP04, RP05) disks* 

(2 or more drives) 

32 

Above with 768K-byte memory and 
a disk drive (or fixed-head disk) 
set aside for the root file system 

40 

VAX-11/780; lM-byte memory; 
at least 3 RP06 disks* 

48 


* Or equivalent. 


t UNIX is a Trademark of Bell Laboratories. 
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See Setting Up UNIX for the list of supported hardware options. 

3. DISK FREE SPACE 

Making files is easy under UNIX. It has been said that the only standard thing about all UNIX systems is the 
message-of-the-day telling users to clean up their files. Administratively, both free disk blocks and free 
inodes (UNIX talk for file headers) can be a problem. If the free inode count falls below 100, the system 
spends most of its time rebuilding the free inode array. If a file system runs out of space, the system prints 
“no-space” messages and does little else. To avoid problems, the following start-of-day free counts should 
be maintained: 

• The file system containing /tmp (temporary files): 

— 16-user system: 1,500 free blocks. 

— 40-user system: 3,000 free blocks. 

• The file system containing /usr\ 

— 3,000 to 6,000 free blocks, depending on load. 

• Other user file systems: 

— 6% to 10% free, depending on user habits (3,000 blocks minimum). 

This brings up an associated problem: how big should file systems be? Our preference is to set aside space 
on each drive for a copy of root/swap and use the rest of the pack for a single file system. However, if you 
have user groups that fight over disk space, it may be better to split them up arbitrarily (i.e., divide a pack 
into more than one file system). Warning: if you set up different disk drives with differing cylinder 
partitions between file systems, it will probably lead to an operations goof someday. 

4. A VERY FEW WORDS ABOUT SYSTEM TUNING 

• As shipped, UNIX has no programs with the text-bit mode set (see chmod( 1)). The top contenders for 
the t-bit are nroff and trojf followed (generally) by the larger phases of the C compiler (including the 
assembler and loader). The t-bit is only meaningful with pure text programs (ld( 1) options -i or -n). 
Don’t overdo it, and keep t-bit programs in the root file system. 

• File system reorganization (described below) can help throughput, but at the expense of down time. If 
you do it when your users are all asleep, it can help. 

• If you use normal shutdown and filesave.u procedures, the file system check program (fsck( 1M), —S 
option) will help keep the disk free list in reasonable order. 

• Try to keep disk drive usage balanced. If you have over 20 users, the root file system {/bin , /tmp, /etc, 
and swap) deserves a drive of its own. 

• If you have a noisy modem (poorly executed do-it-yourself null-modem) or a disconnected modem 
cable, UNIX will spend a lot of CPU time trying to get it logged in. A random check of systems 
uncovers a lot of this going on. 

5. WHY YOU MUST HAVE A SPARE DISK DRIVE 

• Without a spare disk drive, the system will be down when a drive is down. 

• Without a spare drive, it is difficult to reorganize file systems or to restore user files. 

6. DISK PACKS 

• Buy only fully ECC correctable packs and test them. 

• If a pack develops uncorrectable errors, recondition it, or get rid of it. 

RP06 disk packs used with UNIX need not be totally error-free, but must be “flag-free”. The term flag-free 
means that there should be no unrecoverable ECC (Error Correcting Code) errors. Technically, proper ECC 
handling can recover from 11 -bit error bursts. However, we hear that the length of bursts can grow as a 
pack ages. We recommend that no pack that has more than 8-bit error bursts be accepted. For the PDP-11, 
the following explanation may help (paraphrased from a DEC source). 
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In reading the formatter printout, ECC correctable errors are identified by the headings “DATA ERROR 
DURING WRITE CHECK.” Error-register values are printed below the message. The two registers of 
interest are RPER1 and RPEC2. A RPER1 value of 1000000 indicates ECC (no other bits on). The RPEC2 
register describes the bit span of the error. For example, RPEC2=003774 means that there was an 
unacceptable 9-bit (binary 0000011111111100) error burst; RPEC2=000240 is an acceptable 3-bit span 
(000000001 OlOOOOOthere may be zero bits mixed in). If such acceptable errors account for all 
“unrecoverable” errors reported (and there aren’t too many of them), then you have a flag-free pack. 

On the VAX, even this scant information was not available, so we have written our own formatter (it tells its 
tale in English); see rp6fmt{ 8). We plan to make this program available in the future (along with other 
UNIX-oriented diagnostics) for the PDP-11 as well. 

7. PROTECTING USER FILES 

Users, especially inexperienced ones, occasionally remove their own files. Open files are sometimes lost 
when the system crashes. Once in a great while, an entire file system will be destroyed (picture a disk 
controller that goes bad and writes when it should read). Here is a suggested file backup procedure: 

• Each day, copy all user file systems to backup packs. Keep these packs 3 to 5 days before re-using 
them. 

• Once a week, copy each file system to tape. Keep weekly tapes for 8 weeks. 

• Keep bi-monthly tapes “forever” (they should be re-copied once a year). 

The most recent weekly tapes should be kept off premises. The other tapes should be in a fire-proof safe, if 
you can afford one. 

When UNIX goes down, active files can get scrambled. Your users will not want to start the day over every 
time your system fails. In addition to good backup, you must have file-system patching expertise available 
(on-site or on-call). If you ever re-boot the system for general use without checking out the file systems, 
terrible things will happen (we once had five duplicate entries on a file-system free list-this ruined over 100 
new files in just three days). Study fsck( 1M) and crash( 8), as well as FSCK-The UNIX/TS File System 
Check Program. 

8. UNIX FILE SYSTEM BACKUP PROGRAMS 
The following backup programs are distributed: 

• Dump/restor : This is a familiar tape-based system that has been used for several years. Full dumps are 
usually taken when the dump program warns that an incremental dump will run to more than one reel. 

• Find/cpio : UNIX is distributed in cpio format. The -cpio option of the find command has made it 
time-competitive with dump/restor. However, it does not produce a “perfect” restore from a full dump 
plus incremental dump (new and changed files are OK, but file removal information is lost). Because of 
this, full dumps should be taken fairly often (weekly/bi-weekly). Cpio is the only program listed here 
that makes system-independent copies. It can be used to move files between various versions of 
UNIX/RT and UNIX, and can be used in system conversion. 

• Volcopy : physical file system copying to disk or tape. For those who can afford a spare drive, volcopy 
to disk provides convenient file restore and quick recovery from disk disasters (remember the spare 
drive). Tape volcopy provides good long-term backup because the file system can be read-in fairly 
quickly, mounted, and browsed over. Disk and tape volcopy are generally used together for short- and 
long-term backup. Volcopy can also be used for full dumps with either dump/restor or cpio/find. 

The table below summarizes attributes of these programs. The file system size is 65,500 blocks in all cases; 
times are in minutes; judgements are subjective. 
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dump/restor 

find/cpio 

volcopy (disk) 

volcopy (tape) 

Full dump time 

40 

40 

2 

15 

Incremental dump time 

6 

7 

- 

- 

Full restore time 

40(?) 

80 

2 

15 

Incremental restore time 

8 

10 

- 

- 

Ease of restoring: 

one file 

fair 

fair 

good 

fair 

a directory 

poor 

fair 

good 

good 

scattered files 

poor 

poor 

good 

good 

full restore 

fair 

fair 

very good 

good 

Needs tape drive 

yes 

yes 

no 

yes 

Needs spare file system 

(only when restoring) 

no 

no 

- 

yes 

Needs spare disk drive 

(two CPUs can share) 

- 

- 

yes 

- 

Maintains pack/tape labels 

no 

no 

yes 

yes 

Handles multi-reel tape 

yes 

yes 

- 

yes 

512 blocks per record 

1,10 

1,10 

88 

10 

Interactive 

(i.e., ties up console) 

no(?) 

yes 

yes 

yes 

May require separate 

ID space 

no 

no 

no* 

no 


* Blocks per record are cut to 22 without separate I/D space. 


We strongly recommend the spare disk drive: as explained in Section 5 above, the speed and convenience of 
volcopy are by no means the only advantage of a spare drive. 

9. CONTROLLING DISK USAGE 

If your UNIX system is a success, you will soon run out of disk space: 

• During the considerable delay before you can get more drives, you will need to control usage: 

— Try to maintain the start-of-day counts recommended above. Watch usage during the day by 
executing the df command regularly. 

— The du( 1) command should be executed (after hours) regularly (e.g., daily) and the output kept (in 
an accessible file) for later comparison. In this way you can spot users who are rapidly increasing 
their disk usage. 

— Thefind(l) can be used to locate inactive (or large) files. Example: 

find / -mtime +90 -atime +90 -print >somefile 

records in “somefile” the names of files neither written nor accessed in the last 90 days. Of course, 
this works best if you are super-user. 

• You will also have to balance usage between file systems. To do this you will have to move user 
directories. Users should be taught to accept file system name changes (and to program around 
them-preferably ahead of time). The user’s login directory name (available in the shell variable HOME) 
should be utilized to minimize path name dependencies. User groups with more extensive file system 
structures should set up a shell variable to refer to the file system name (e.g.: FS). 

• The find(l) and cpio( 1) commands can be used to move user directories and to manipulate the file 
system tree. The following sequence is useful (it moves, via magnetic tape, the directory trees userx 
and usery from file system, filesy si to file system filesysl where, presumably, more space is available): 
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cd /filesysl 

find userx usery -cpio /dev/rmtO 

cd /filesys2 

mkdir userx usery 

chown userx userx 

chown usery usery 

cpio -idmB </dev/rmtO 

# Make sure new copy is OK 

# Change userx and usery login directories in the /etc/passwd file 
rm -rf /filesysl/userx /filesysl/usery 

When moving more than one user in this way: 

■ — Keep users with common interests in the same file system (they may have linked files). 

• — Move groups of users who may have linked files with a single cpio (otherwise linked files will be 
unlinked and duplicated). 

10. REORGANIZING FILE SYSTEMS 

The procedure for moving users described above can be expanded to provide a way to reorganize whole file 
systems. Reorganization can improve system response time. This is particularly true of the root file system 
(which must be reorganized with all other file systems unmounted) and/twr. Unfortunately, reorganization 
of large file systems is slow. 

11. KEEPING DIRECTORY FILES SMALL 

Directories larger than 5K bytes (320 entries) are very inefficient because of file system indirection. A 
UNIX user once complained that it took the system ten minutes to complete the login process; it turned out 
that his login directory was 25K bytes long, and the login program spent that time fruitlessly looking for a 
non-existent .profile file. A large /usr/mail or /usr/spool/uucp directory can also really slow the system 
down. The following will ferret out such directories: 

find / -type d -size +10 -print 

Removing files from directories does not make the directories get smaller (the empty directory entries are 
available for reuse). The following will “compact” / usr/mail (or any other directory): 

mv /usr/mail /usr/omail 
mkdir /usr/mail 
chmod 777 /usr/mail 
cd /usr/omail 

find . -print | cpio -plm ../mail 
cd .. 

rm -rf omail 

12. ADMINISTRATIVE USE OF “CRON” 

The program cron(lM) is useful in the administration of the system; it can be used to: 

• Turn off the programs in directory /usr/games during prime time. 

• Run programs off-hours: 

— accounting; 

— file system administration; 

— long-running, user-written shell procedures (using the sm( 1) command), for example: 

su - userx userx_shell arg ... 
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13. WATCH OUT FOR FILES AND DIRECTORIES THAT GROW 

• Accounting files: 

— /us r/adm/wtmp login information; 

— /usr/adm/pacctpiocess accounting; gets big quickly. 

• Other files: 

— /usr/lib/cronlog status log of commands executed by cron{ 1M); 

— /usr/spool spooling directory for line printers, uucp( 1C), etc., and whose sub-directories should be 
compacted as described above. 

14. ALLOCATING RESOURCES TO USERS 

A prospective user should obtain connect-time and file-space authorization through appropriate channels. 
Once this is done, the user should apply for a login by providing the following information to the “system 
administrator”: 

• User’s name. 

• Suggested login name (not more than 8 characters, beginning with a lower-case letter). 

• Relationships to other users (this influences the choice of the file system). 

• Estimate of required file space (this also influences the choice of the file system). 

Users should be forced to have passwords (not more than 8 characters long, but more than 5, and not in 
Webster’s Unabridged); passwd( 5) explains how to do that. 

15. THE MATTER OF ACCOUNTING AND USAGE 

You should run the accounting programs even if you do not “bill” for service. Otherwise, your users’ 
habits (especially bad habits) will be a mystery to you. Accounting information can also help you find 
performance bottlenecks, unused logins, bad phone lines, etc. 

16. DIAL LINE UTILIZATION 

If prime-time dial line utilization gets much over 70%, users will start to encounter busy signals when 
dialing in. This, in turn, will lead to “line hogging”. The only solutions are to get a larger (another) 
machine, or to get rid of users. Manual policing will help some, but “automatic” policing will be 
invariably subverted by users. 

17. “BIRD-DOGGING” 

When the system is busy (lines busy and/or slow response), someone should determine why this is so. The 
who(\) command lists the people logged in. The ps(\) command shows what they are doing. (The 
/etc/whodo command combines the output of who and ps.) Unfortunately, ps operates from heuristics that 
can consistently fail to report certain processes in a busy system. That is, one must be careful about 
hanging up an apparently inactive line. The acctcom{ 1M) command can read the shell accounting file 
/usr/adm/pacct backwards from the most recent entry. It will print entries for selected lines or login names. 

18. 300/1, 200-BAUD TERMINALS 

Don’t use upper-case-only terminals. Get full-duplex, full-ASCII terminals. Hardware horizontal tabbing is 
very desirable, because it increases output speed and lowers system overhead. A fair proportion of your 
terminals should provide for correspondence-quality hard-copy output to take advantage of the UNIX word- 
processing capabilities; see term{l). 

19. LINE PRINTERS 

Most line printers are troublesome and impose considerable overhead on the system. Most also lack 
hardware tabs, character overstrike capability, etc. A printer that will work over an asynchronous link 
(DC1/DC3 protocol required) may be the best bet. 
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20. SECURITY 

The current UNIX is not tamper-proof. You can’t keep people from “breaking” the system, but you can 
usually detect that they have done so. The following command will mail (to root) a list of all “set user ID” 
programs owned by root (super-user): 

find / -user root -perm -4100 -exec Is —1 { } \; I mail root 

Any surprises in root’s mail should be investigated. Related advice: 

• Change the super-user password regularly. Don’t pick obvious passwords (choose 6-to-8 character 
nonsense strings that combine alphabetics with digits or special characters). 

• If you have dial ports and do not require passwords, you are courting trouble. 

• The chroot{ 1M) ans sk( 1) commands are inherently dangerous, as are group passwords; consider 
removing them from “production” systems. 

• Login directories, .profile files, and files i n /bin , /usr/bin , Abin , and /etc that are writable by others than 
their respective owners are security weak spots; police your system regularly against them. 

• Remember, no time-sharing system with dial ports is really secure. Don’t keep top-secret stuff on the 
system. 

21. COMMUNICATING WITH YOUR USERS 

The directory /usr/news and the news( 1) command are provided as a way to get brief announcements to 
your users. More pressing items (one-liners) can be entered in the /etc/motd (message of the day) file; 
motd and (new to the user) news are announced at login time. 

To reach users who are already logged in, use the wall{XM) (write all) command. Don’t use wall while 
logged-in as super-user, except in emergencies. 

The /usr/news directory should be cleaned out every few weeks so that nothing older than, say, three 
months is ever found there. The motd file should be cleaned out daily. 

We have found that, on most systems, a file in /usr/news will reach 50% of the users within a day and over 
80% of the users within a week. 

22. TROUBLESHOOTING 

It would be easy to write a book on this topic. The following are some of the key items: 

a. Dealing with the hardware service contractor: 

• Before you take out a hardware service contract (with DEC or with someone else), be sure that the 
contractor agrees to get along with the UNIX software (“It’s the hardware,” says you; “It’s the 
software,” says the hardware service contractor). 

• Keep on top of problems. For instance, DEC has a problem-aging priority scheme. Find out 
about any such scheme that your contractor may have, and make them prove that it is being 
followed. Remember that an unreported problem is getting no priority at all. If a problem 
persists, escalate it up your contractor’s local management chain; it may also be effective to 
complain to your contractor’s sales representative. 

• If you are serious about service to your users, you should have an extended-period service 
contract (e.g., 16 hours/day, 6 days/week). Arrange for preventive maintenance, non-critical 
repair, and add-on installation work to be done before or after prime time. 

• If you have a service contract, learn the details. In particular, make sure that preventive 
maintenance is scheduled in advance and that it is completed. 

• Ask the hardware service contractor to provide and maintain a “site log”. You will have to work 
on the log, as well. 

• Make sure that your hardware vendor (as well as your hardware service contractor, if the two are 
different) agrees to the presence of non-DEC equipment on your system (even if you have none to 
start with). 
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• Run error logging. Keep console sheets. Make sure error messages are shown to your 
contractor’s Customer Engineers. 

• Take core dumps after system crashes and interpret results for Customer Engineers. 

• Keep down-time records and make sure that your hardware service contractor knows about them. 

b. Dealing with the telephone services vendor: 

You are most apt to have telephone problems when you rearrange or add equipment. You may also 
have occasional central office, trunking, and modem failures: 

• Be specific with repair operators: tell them that the trouble involves data equipment. 

• If your first call fails to get results, ask for the “supervisor” on the second call, and, if necessary, 
escalate further to get the problem solved. 

c. Some obvious problem areas: 

• Disk Drives-Over 50% of your problems are likely to be related to the disk subsystem. As 
mentioned earlier, the way to keep your system up is to have a spare disk drive. Remember: 

— Preventive maintenance of disk drives is very important. 

— Make sure that the Customer Engineers who service your hardware see the error-logging 
printouts and console error messages produced by UNIX (and that they understand them). 

— Disk failure can ruin a UNIX file system. The only defense is to make a complete, daily file 
backup! (See Protecting User Files above.) 

— Many administrators believe the the RP04 disk drives fail more often than RP06s and take 
longer to fix. 

• Dial Ports-In this area, as well as in the area of synchronous data interfaces, there is room for 
finger-pointing among all your vendors. Check for obvious things: 

— Is the system in “multi-user” mode? 

— Is the /etc/inittab file OK? 

— Are any cables loose ( both ends)? 

— In some telephone offices, trunk-hunting is based on 10-number groups. Hunting between 
such groups can fail independently of anything else. 

The possibilities for trouble are many. The “decision table” below attempts to describe some 
alternatives; it is meant primarily for users of DH11/DZ11 asynchronous devices. If you are 
unfamiliar with the format, (vertical) Rule 3 reads: “If line rings and ring light shows and 
computer does not answer and switching the modem solves the problem, then it is likely to be a 
telephone company problem; also, busy out that line.” 

• Early experience with the DZ11 has been poor. Several different problems have cropped up 
including bad line units and a stuck interrupt bit that crashes the system. Don’t install DZs 
without giving them the full diagnostic treatment. 

• Synchronous Ports-High-speed synchronous interface devices are even more trouble than dial 
equipment. The following is a list of potential trouble spots: 

— Your UNIX software. 

— Your interface device (e.g., DQS1 IB). 

— Cable to your modem. 

— Your modem. 

— The communications line. 

— - Other modem. 

— Other cable. 

— Other interface device. 

— Other system’s software. 

Think of the finger-pointing possibilities. The best defense is a good line monitor. 

• Power Supply Modules-There are a lot of them, and they do fail, more or less regularly. Hard 
failure can be detected at the console; voltage drift is tougher. Failure of the FP1 1 (floating-point 
unit) power supply can be slow to fix, because Customer Engineers are likely to work back from 
the far end of the “bus”, taking a long time to find the problem. 
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Asynchronous Line Problems 

Rules: 1234567890 

Condition: 

Line rings 

Ring light shows on telephone console 
Computer answers 
Login message received on terminal 
Switching modem solves problem 
User can login 
Telephone console shows data received 
Problem affects whole DH/DZ (up to 16 lines) 

Diagnosis and/or Action: 


No problem ---------X 

PDP-11 hardware problem likely X-XX 

Telephone problem likely XXX-X - - — X — 
May be a problem with user’s terminal -------X-- 

Busy out bad line(s) XXXXXXX-X- 


NYYYYYYYYY 

-NYYYYYYYY 

NNYYYYYY 

NNYYYY 

YNYN 

NNNY 

Y Y N — 

YN 


23. DATASET OPTIONS 

The following dataset options seem to work with UNIX: 

The 801C-L1 (Auto-Call Unit): 

Jumpers: 

E2 to E3 
E6 to E5 

Options: 

Y, X, T, B, 

ZG, ZP, G, 

R, ZT 

Switches (0 = open, 1= closed, i.e., side next to number is down): 

51 = 1000[1] (Bracketed switches are missing on some models.) 

52 = 0101 

53 = 11010 

54 = 11 [00] 

The 212A-L1 (1,200-baud full-duplex): 

Options: 

E, ZF, YF, YC, 

YG, YJ, YK, 

S, V, A, T, ZH, 

W, YP, YR 

Switches: 

51 = [ 0]001 

52 = 110001000 

53 = 11110000 

55 = 00 


24. NULL MODEM WIRING 

Improperly wired null modems can cause spurious interrupts, especially at higher baud rates. A single bad 
modem on a 9,600-baud line can waste 15% of your CPU power. The following (symmetrical) wiring plan 
will prevent such problems: 
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pin 1 to 1 
pin 2 to 3 
pin 3 to 2 

strap pin 4 to 5 in the same plug 

pin 6 to 20 

pin 7 to 7 

pin 8 to 20 

pin 20 to 6 and 8 

ground unused pins 

25. 113D, 103J DATA SET PROBLEMS 

The DH11 and DJ11 multiplexers normally have a jumper connecting pin 25 to pin 4 (request to send), thus 
asserting pin 25 when the line is opened. This jumper should be removed for any lines connected to 1 13Ds 
or 103Js (also applies to 103Js with 801s). 

26. PHOTOTYPESETTING EQUIPMENT AND SUPPLIES 

Read this section if you plan to use the phototypesetting software of UNIX. 

Phototypesetter. The phototypesetter and fonts currently supported by UNIX are manufactured by: 

Wang Graphic Systems, Inc. 

Executive Drive 

Hudson, NH 03051 (603-889-8550) 

The phototypesetter is an on-line C/A/T System 1 with a high-speed turret. The external paper tape reader 
on the typesetter is not needed, because the typesetter is connected to the PDP-1 1 CPU via a DR 1 1C. 

PDP 11/45 Only. The following modification (developed by DEC Field Service) should be made to the 
DR11C (without this modification, the system may crash when the typesetter is powered down): “Add two 
390-ohm resistors-from E-18 pin 6 to ground, and from E-18 pin 3 to ground. Put a piece of insulating 
tubing over the leads so that they do not short out the ‘etch’ runs that they cross.” 

Fonts. There are eight fonts that are normally used, as shown in the table below. The first three of the 
these provide the most-often used (serif) typeface. The last three are used when a sans-serif typeface is 
desired. The fourth font contains a number of Greek characters and mathematical symbols; see 
NROFF/TROFF User’s Manual by J. F. Ossanna. The fifth font is useful for typesetting text that you wish 
to look like terminal or printer output, e.g., for examples of programs. Wang Graphic Systems, Inc. offers a 
variety of other fonts. For trojf to be able to use these fonts, corresponding font tables must be built and 
compiled into the directory /usr/lib/font . 


Name 

Part Number 

Trojf Name 

BT Times Roman 

802-0 16A 

R 

Times Italic 

802-013A 

I 

Times Bold 

802-014A 

B 

BT PI Font #4 Special Characters 

829-021B 

S 

BT PI Font #6 Constant Width 

829-046A 

cw 

Geneva (Helvetica) Regular 

803-032B 

G or H 

Geneva (Helvetica) Regular Italic 

803-033B 

GI or HI 

Geneva (Helvetica) Medium 

803-034B 

GM or HM 


Other fonts for which the source font tables are supplied are: 
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Name 

Trojf Name 

Boston Condensed 

BC 

News Condensed 

C 

Century Schoolbook Expanded 

CE 

Century Schoolbook Italic 

Cl 

Century Bold Italic 

CK 

Century Schoolbook 

CS 

Futura (Utica) Demibold 

FD or UD 

Text Greek 

GR 

Geneva Light 

L 

Geneva Light Italic 

LI 

Palatino 

PA 

Palatino Bold 

PB 

Palatino Italic 

PI 

Stymie Bold 

SB 

Stymie Medium Italic 

SI 

Stymie Medium 

SM 


Paper and Chemicals. The phototypesetter “prints” onto photo-mechanical paper, which can be obtained 
from a photographic supply house and is specified as: 

• Kodak Ektamatic Paper, Grade S, Type 2250, 8 in.xl50 ft., Spec. 175 (or equivalent). 

Also obtainable from such a supply house are the chemicals for the developing process: 

• Kodak Ektamatic A10 Activator (or equivalent). 

• Kodak Ektamatic S40 Stabilizer (or equivalent). 

These chemicals should be ordered in 9.5-liter (2.5-gallon) containers for the circulator. 

Developer. A Kodak Ektamatic Processor Model 214K (or equivalent) is used to process the paper from 
the typesetter. A light-proof box attached to the 214K (to hold the output cassette from the typesetter) is 
called an “Autofeeder” and can be obtained from: 

Peripheral Graphics, Inc. 

Andover Industrial Center 
York Street 

Andover, MA 01810 (617-475-9005) 

Circulator and Dryer. A circulator and a paper dryer, as well as a shelf for the dryer can be obtained 
from: 

Mohr Enterprises 

8015 North Ridgeway Ave. 

Skokie, IL 60076 (312-674-8890) 

The needed parts are: 

• ME-8 Mohrflow: circulator to increase the usability of the chemicals. 

• ME-5 Mohrdry: dryer for the photo-mechanical paper. 

• Dryer Extension: shelf to support the dryer; it connects to the circulator cabinet. 

Also obtainable from Mohr Enterprises are cleaners for the developer and circulator. Such cleaning is 
needed every 2 to 4 weeks, depending on the volume of work: 

• R-53 Mohrchem Activator Cleaner Concentrate. 

• R-57 Mohrchem Stabilizer Cleaner Concentrate. 

Each quart bottle makes 9.5 liters (2.5 gallons) of reusable cleaner to clean the tubing, rollers, and tray of 
the developer and circulator. Equivalent cleaners can also be obtained elsewhere. 
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